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SCAN TOOL WITH 
DROPPED COMMUNICATIONS DETECTION AND RECOVERY 
AND IMPROVED PROTOCOL SELECTION 

This application is a continuation of s U.S. Non-provisional application Serial 
No 10/159,957 filed on May 31, 2002, and entitled SCAN TOOL WITH DROPPED 
COMMUNICATIONS DETECTION AND RECOVERY AND IMPROVED PROTOCOL 
SELECTION, which is hereby incorporated by reference in its entirety. Non-Provisional 
Application Serial No. 10/159,957 claims priority to U.S. Provisional Application Serial No. 
60/295 318, filed on June 1, 2001, and entitled SCAN TOOL WITH DROPPED 
COMMUNICATIONS DETECTION AND RECOVERY AND IMPROVED PROTOCOL 
SELECTION, which is hereby incorporated by reference in its entirety. Non-Provisional 
Application Serial No. 10/159,957 claims priority also claims priority to U.S. Provisional 
Application Serial No. 60/385,084 filed May 30, 2002, also entitled SCAN TOOL WITH 
DROPPED COMMUNICATIONS DETECTION AND RECOVERY AND IMPROVED 
PROTOCOL SELECTION, and listing Messrs. Namaky, Sheppard, and Gessner as 
inventors, which is hereby incorporated by reference in its entirety. 
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FIELD OF THE INVENTION 

The present invention relates generally to the field of electronic testing 
devices, and more specifically to an improved "off-board device," such as an OBD II scan 
tool, having dropped communications detection and recovery and further having improved 
protocol selection. 
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BACKGROUND OF THE INVENTION 

"Off-board devices," sueh as scar, tools, are known in the art and are testing 
devices that interface with vehie.e diagnostic systems to access, display, and/or prim vehrc.e 
diagnostic —ion. OBD I. (On-B„ard Diagnostics version II) Scan Tools are one 

J1978 Rev. 1988-02 and SAE J1979 Rev. 1997-09. 

There are a nnmber of problems with tire existing scan tools and scan tool 
specifications. For example, in certain vebic.es, e.g., various mode, years of HYUNDAI, 
VW DODGE, and VOLVO vehicles, .he known scan tools have communications drop-on,, 
One minnte the oser will be using a scan too. and be examining e.g., 28 different parameter, 
and the next rnstan. there is no response for a., hot e.g., three, of the parameter, What the 
user does no, know is ,ha, one or more controUers, e.g., the engine controUer, whtc ,s 
typi ca,ly the main ODB .. controller, has dropped on,, leaving only a secondary controller, 
e ^ a transmission contro.ler, talking with the scan tool. The known sean tools must begtn 
.he entire session over again, which can take half a minnte or more and must be prompted by 
the user. As another example, sometimes following the specifications for determmtng fit 

Ltmation (e.g., fire most emissions infomration). Following the specifications, a scan too. 
mi ght seleo, a protocol that ends up with far less emissions data man another protocol 

More specifically, protocol determination is automatic (hands off) 
determination of which —cation protocol the vehicle is using for the OBD .1 
action, Some vehicles have multiple modules and these modules may use Afee 
communication protocols. But only one of these protocols contams all the OBD I 
information for the vehicle. Therefore, the scan too, mus, he able to determtne whrch 
prot oco, is the correct one to use for OBD II purpose, This automatic determmatron ,s 
pecified in a SAE 1.978. Furthermore in section 6.4.1 and 6.4.2 fire SAE has spe led out a 
pledure for trying the four (4) protoco, and defining which one is the OBD I. protoco, 
Lpported by the vehicle to relate the appropriate functions. In section 6.4.1 the spectfienfio. 
spells on, that on,y one protocol is allowed to be used in any one vehicle ,o access a . the 
0 supported OBD II function, This does no, mean than a vehicle cannot support more that one 
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sugg es t edmeftodforde.en„im n g.heOBDIIpro.ocon„J197 8 sectio„6.4.2. 

Ttaough on-vehicle testing the inventors of the present invention dtseovered 
fta. this recommended way has flaws: one ends np seeing Are wrong proftcol as the OBD 
5 n link. Therefore a sean too, Mowing the reeontmendation is unable to determtne he 
correot protoeo. and therefore unahte to use an fte eovered OBD .1 Amotions and read afl Are 
availabie —ion Aom the vehic.e. One of flte vehicles in question, for example, , one 
fta, supports 00th ,S0 9,4,-2 (ISO) and ISO ,4230-4 (Keyword 2000, The engtne eo» tt o, 
m „du,e uses ISO 14230-4 as its protoeo. and the transaxle eontrol module uses ISO 914W. 
,„ The engine eonno.Ie, is Are module that supports .he OBD 1. Amotions for ,he vehtc.e. Bu. 

4 . t wfnrTSO 9141-2 first and if one receives a 
the SAE suggested procedure d,rec«s mat one test for ISO 9141 hrs 

rep ,y, then that waa the protocol to use for the 1* I, is the same wtft ISO 14230- tf* 
re phes. Thrs causes me scan too, to incorrectly che.se the protoeo. hetng used hy 
Lie as the OBD II protocol for ftis type of vehicle rather than the proems i - 
15 by the engine controller. Now that the scan too. is using the wrong protocol, ISO 9141-4, 
only lug to the tiansaxle controller. The engine controller (and all the em,s,o„ 
iuformltion it has ,o offer) is no. found. This type of prohlem can happen m oflter pro.oco, 
combinations also. 

Also certain vehicles employ multiple modules that commumcale usmg me 
20 same pro-ocol. Thil .ype of system is suhject to one or more of me modules .o losmg men 
active communication with off-hoard devices, like scan -ools. If .he sean too, does no. 
re a,ize ft, one or more of fte modules has dropped fte .ink, i. will no, he showmg 
c„ mp le.e/corree^da.a^ ^ ^ ^ ^ ^ ^ ^.^ 

25 m odu,e vehtcles presen. certain prohlems. For e X amp,e certain VW models ft, use - 
engtae conuo. module and a .ransax.e conuol module presen.ed a problem. AAer 
defining the OBD II protocol and initializing hoft modules for communications, ,, :~ 
noticed ft, one or fte ofter module wou.d occasionafly s.op —eating. Thts prob, m 
coul d be seen while requesting information on several Amotions, such as fte 
30 Amotion (a,so known as the "Live Data" Amotion). For examp.e, user migh, notice dunng 
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one View Data session .hat two modules report .he state of .he Malfunction Indieator Lamp 
("MIL") and might notice on a subsequent View Data session on the same vehiele that only 
one module reports the MIL'S state. The MIL'S state from the other modules ts now 
unknown. What happened is that, unknown to the user, one of the eonfrollers dropped the 
5 eommunications link, so it did not respond to the request for the state of the MIL. These 
problems can result in OBD II information being misreported. 

There is a need, therefore, for an improved scan tool. 

SUMMARY OF THE INVENTION 
The present invention is directed toward an improved "off-board device." In 
10 one embodiment, the "off-board device" of the present invention is a scan tool. According to 
one aspect of the present invention, .he improved scan tool uses a novel method of 
determining the proper protocol to use to communicate with a vehicle computer network. 
According to another aspec. of the present invention, .he improved scan tool de.erm.nes and 
automatically tecovers from a communications drop-out. The scan tool of me presen. 
15 invention preferably, bu. no. necessarily, includes bom .he novel method of detetmtnmg the 
proper protocol to use to communicate with a vehicle computer network and the 
determination and automatic recovery from a communications drop-out. 

It is therefore an advantage of the present invention to provide an improved 
scan tool that determines the protocol that provides me most relevart. vehicle information 
20 (eg the protocol thai provides the most emissions information). 

It is also an advantage of the present invention to provide an improved scan 
tool that determines when a module has had a communications drop-out. 

It is another advantage of the present invention to provide an improved scan 
tool that automatically recovers from a communications drop-out. 
25 It is a further advantage of this invention to provide an improved scan toot that 

automaticaify recovers from a communications drop-out withou, requiring that fhc protocol 

be re-determined. ? 

It is yet another advantage of the present invention to provide an improved 
scan tool that determines when a module has had a communications drop-out and that 
30 automatically recovers from a communications drop-out. 
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These and other advantages of the present invention will become more 
apparent from a detailed description of the invention. 

BRIEF DESCRIPTION OF THE DRAWINGS 
In the accompanying drawings, which are incorporated in and constitute a part 
of this specification, embodiments of the invention are illustrated, which, together with a 
general description of the invention given above, and the detailed description given below, 
serve to example the principles of this invention, wherein: 

Figure 1 is a high-level block diagram of a scan tool according to the present 

invention; 

Figure 2 is a block diagram of a specific implementation of a scan tool 
according to the present invention; and 

Figures 3-7 are flow charts showing the novel methods used by the scan tool 
of Ae present invention to select the proper protocol, determine whether a communications 
drop-out has occurred, and recover from a communications drop-out. 

DETAILED DESCRIPTION OF THE INVENTION 

Referring to Figure 1, a high-level block diagram of both a typical scan tool 
and a scan tool 10 of the present invention is shown. Such a scan tool 10 comprises a 
processor system 12 in circuit communication with a communication circuit 14, a d.splay 16, 
20 one or more input devices 18, and optional additional storage devices) 20. 

-Circuit communication" as used herein indicates a communicative 
relationship between devices. Direct electrical, electromagnetic, and optical connections and 
indirect electrical, electromagnetic, and optical connections arc examples of crcut. 
communication. Two devices are in circuit communication if a signal from one is recewed 
25 by the other, regardless of whether the signal is modified by some other devrce. For 
example, two devices separated by one or more of the following-amplifiers, filters, 
transformers, optotsolators, digital or analog buffers, analog integrators, other electron* 
circuitry, fiber optic transceivers, or even satel.i.es-are in circuit communication tf a stgnal 
from one is communicated to the other, even though the signal is modtfied by the 
30 intermediate device(s). As another example, an electromagnetic sensor is m ctrcut. 
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co.mnumca.ion with a signal if it recetves electromagnetic radiation from the srgnal. As a 
final example, two devices no. directly connected to each other, hot bo.h capable of 
interfacing with a third device, e.g., a CPU, are in circuit communication. Also, as used 
herein, voltages and values representing digitized voltages are considered to be equivalent for 
5 the purposes of this application and thus toe term "voltage" as used herein refers to etther a 
signal, or a value in a processor representing a signal, or a value in a processor determmed 

from a value representing a signal. 

The scan tool 10 is placed in circuit communication with a vehicle computer 
network 30 having one or more interconnected compute, ("modules") via a connection link 
,0 carried by a communication cable 32. The connection cable 32 typically has a connector 34 
affixed thereto drat connects to a mating connector 36 in circuit communication wrth the 

vehicle computer network 30. 

The processor circuit 12, also referred to herein as just processor 12, may be 
one of virtually any number of processor systems and/or stand-alone processors, such as 
15 microprocessors, microcontrollers, and digital signal processors, and has assoctated 
therewith, eiflrer internally therein or externally in circuit communication therewtth, 
associated RAM, ROM, EPROM, clocks, decoders, memory controllers, and/or tnterrup. 
controllers, e.c. (all no, shown) known to those in the art to be needed to implement a 
processor circuit. Figure 2 shows a high-level block diagram of an exemplary scan too. ustng 
20 an MC68306 processor * implement a scan tool having a generic vehicle tn.erface and a 
specific vehicle interface, and a cartridge EPROM. 

The communications circuit 14 typically generates one or more 
communications protocols with which Use scan too. .0 and tire vehicle computer network 30 
communicate with one-another. The communications circuit 14 can be implemented Cher 
25 in hardware, or in software, or in a combination of hardware and software. Typtcal 
communications protocols generated by the communication circuit 14 of scan tools tnclude 
but are no, limited ,o: SAE 11850 (VPW), SAE 11850 (PWM), ISO 9141-2, and ISO 14230- 
4 (-Keyword 2000"). The present invention is not intended to be limited to any spectfic 
protocol, or even to electrical commumcations protocols. Other present and future protocols, 
30 such as fiber optic and wireless communications protocols, are also contemplated as betng 
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within the scope of the present invention. The display 16 can be one or more of virtually any 
type of display, e.g., textual displays (such as n character by m line LCD or plasma dtsplays, 
etc ) binary displays (such as LEDs, lamps, etc.), graphical displays (such as LCD dtsplays 
ft* 'car, display text and bar graphs and .he like), etc. The input device(s) typically compnse 
5 one or more Keys or a keyboard, but may be one or more of virtually any type of mpu. 
device, such as touch screens, etc. The optional additional storage device(s) 20 can 
compnse, for example, cartridge memories (such as those containing EPROM, EEPROMor 
Flash PROM memories), cartridge memories, PC cards, stick memories (such as SONY 
brand MEMORY STICK packaged memory semiconductors), so-called floppy dtsket.es, etc. 
10 The processor 12 typically executes a computer program stored m its RAM, 

ROM Flash memory, and/or its EPROM (all no. shown) and/or stored in any of flte 
additional storage device(s) 20, using da.a stored in any one or more of .hose memones. For 
example, the processor 12 may executo a computor pro-am from a ROM (not shown) usmg 
data (e.g., codes) stored in a cartridge memory 20. In general, me computor program 
,5 executed by .he processor in typica. scan tools initializes .he scan too. and genera.es a user 
interface (e.g., using .he inpu. device(s) 18), throng which a user causes tire scan too! to 
communicate with tine vebic.e computer network 30 to read certain date from .he vehtcle 
computer nelwork 30, forma, such read date, and disp.ay the formatted date on me dtsplay 
16 At .his high .evel, the scan tool 10 according to flte present invention works tire same: 
20 .he computer program executed by flte processor 12 initiaUzes the scan too. .0 and generates 
a user interface (e.g., using flte inpu. device(s) 18), through which a user causes flte scan too. 
,0 to communicate with the vehicle computer network 30 to read certain date from flte 
vehicte computer network 30, format such read data, and display the formatted data on the 
disp.ay 16. A fundamental difference in the present invention is how the scan tool 10 of tire 
25 present invention selects a protoco! throng which it communicates with the vehrcle 
computer nenvork 30. Anomer fundamental difference is how .he scan tool .0 of the present 
invention detects and recovers from a dropped communications link. 

Referting now to Figure 3, a high-level flow chart 100 showing the code 
executed by processor 12 to detennine the proper communications protocol with the vehtcle 
30 computer network 30 is shown. In general, the protocol determining routine of the present 
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invention defines which pto.ocol results in the most relevant data (,g., the most OBD n 
emissions data) being available to Are scan tool 10 torn the vehicle computer network 30 and 
selects that protocol as the protocol to use. This necessarily involves cheeking all (or a, least 
many) of the available protocols (or merely selected protocols) and no, merely using the first 
5 protocol with which the scan tool establishes a communications link with the vehrcle 
computer network 30. Of coume, fire scan too. 10 must be connected to the vehicle computer 
network 30 via a suitable cable 32 or other communications medium, e.g., fiber optic or 
wireless medium. The code begins a, step 102. First, at step ,04, a firs, protocol is selected. 
In the case of an ODB II scan tool according to the present invention, the first protocol to test 
,0 might be the SAE J1850 (PWM) protocol. Next, a, 106, the processor 12 causes fine 
communications circuit 14 to attempt to establish a communications link with the veh.e e 
computer network 30 using the firs, protocol. If any modules answer, at step 108, the 
processor 12 causes the communications circni. 14 to request data from the modu.e(s) ustng 
the first protocol, a, 1 10. The data, if any, transmitted by the modules) is stored by protocol 
, 5 and module. More specifically to an OBD II scan too. according to the present invention, at 
step 110, a request that will result in most if not all of the modules responding (such as a 
Mode 1 FID 0 request, or a Mode 1 PID 1 request) is issued and the number of pteces of 
information (in the case of a Mode 1 PID 0 request, the supported PIDs; in the case of a 
Mode I PID 1 request, toe number of "monitors") for all the modules is stored for that 
20 protocol. Then, or if no modules responded a, test 108, the code tests, a. step 112, whether 
a,, the protocols have been tested. If no,, the code branches a. 1 13 to step 1 14, where another 
communications protocol is selected to be tested. The protocols can cither be tested m a 
predetermined fashion, or a random fashion, or a combination of predetermined and random 
Then the code executes again from step 106 through step 112 with the next protocol until all 
25 the protocols (or selected protocols) have been tested. If none of the protocols generated . 
response from any modules, then the code preferably informs tine user of this fact and 
provides the user with guidance and a number of options, as discussed below m the text 
accompanying rusks 338 and 426. If one of the protocols did generate a response from a 
module, then the code branches at 115 to step 116 where the requested data is analyzed to 
30 determine which protocol should be used. In general, the protocol resulting in the most 
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pieces of relevant data being available or transmitted is selected. If there .. a he, a 
predetennined list of priorities, such as those provided in the OBD II specifications or those 
predetermined by some other means, can be used to break me tie. For example, suppose that 
the vehtcle computer network 30 responds to a Mode 1 FID 1 request by reporting 7 momtors 
5 for the ISO protocol and by reporting 8 monitors for the Keyword 2000 protocol; the 
Keyword 2000 protocol would be chosen. Supposing that the vehicle computer network 30 
responds to a Mode 1 PID 1 request by reporting 7 monitors for the ISO protocol and by 
reporting 7 monitors for the Keyword 2000 protocol; the ISO protocol would be selected, 
because mat protocol takes precedence over the Keyword 2000 in me specifications. 
10 Thereafter, the communications circuit 14 communicates with the vehicle computer network 
30 using that selected protocol, as shown at task 118. As shown at step 120, tire scan too. 10 
ten reads and displays data from the vehicle computer network 30 in response to user 
commands, using the selected protocol. 

Another important aspect of the present invention is how the scan tool 10 of 
,5 the present tnvention handles commnnieations drop-outs. In general, the present invention 
determines whether a module has dropped out or has mere.y ignored a request for data. 
Additionally, after a communications drop-out is detected, me present invention preferably 
communicates with the vehicle computer network 30 using the protocol determined by the 
code shown in Figure 3. The scan tool 10 preferably does not re-determine the proper 
20 protocol after a drop-out. The resulting time-savings of half a minnte-or-so might seem to be 
trivial, but to a user it can be significant, especially in a station when eommnnicatron drop- 
outs are frequent. 

Referring now to Figure 4, a high-level flow ehart 200 showing the code 
executed by processor 12 to determine a communications drop-out and recover therefrom is 

25 shown. The code begins at 202 with the scan tool 10 of the present invention determmmg 
how many modules respond to the protocol (e.g., OBD II protocol) being used and stores the 
IDs of the modules. Then whenever requesting data or communicating with the vehicle 
computer network 30, such as at task 204, the scan tool 10 checks to be sure that all the 
modules that previously responded at step 202 answer the request, at 206. If all of the 

30 modules answer, at 208, then there has been no communications drop-out and the code 
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branches and can continue a, 209 either accessing more data or displaying the data, etc. On 
the odter hand, if at 208 one or more of the previously identified ntodu.es does no, respond, 
to code next determine, whether that specific module lost the link or whether that module 
merely ignored me request issued at step 204, e.g., ma. module does no, support me request 
sent On the one hand, if me scan ,ool 10 defines ma, me module tha, did no, respond ts 
stifi communicating via ma, protocol, the scan too, .0 of me present invention assumes that 
th a( module merely ignored me request, e.g., it does no, support me request. On the other 
hand if the non-responsive module is also not communicating in response ,o more bastc 
requests, men me scan tool 10 of me present invention concludes ma, there has been a 
communications drop-out. More specific to Figure 4, if a, 208 one or more of the prevtou* 
identified modules does no. respond, the code branches a, 210 «o s«ep 212, where me co e 
checks and determines again which modules are sti.l .inked, preferably using exady .he 
same method as used in step 202. fir .he context of an OBD II scan ,oo. accordmg to me 
pI esen, invention, if a Mode 1 FID 0 request was issued a, step 202, then a Mode 1 FID 0 
request is preferab.y also issued a, step 212. If a, 214 tire same modu.es are sti.1 .mked m 
response ,o me request issued a, step 2.2 as were .inked a, step 202, then mere has been no 
communications dro P -ou. and the code branches a, 216, and can continue a, 218 Cher 
accessing more data or displaying the data, etc. On the other hand, if a, 2.4 the same 
modules are no. still linked in response «o the request issued a. step 212 as were hnked a, step 
202 ,hen .here has been a communications drop-ou. and the code branches a, 220, where .he 
codl responds .o a communications drop-ou. a. 222. A. 222, a number of things can be done, 
such as re-inttiahzing .he communications link and/or trying tire request a, step 204 agatn 
Trying the recuest a, step 204 again should no, be repeated indefinitely, or the code mtgh, 
end up in an endless loop (as migh. happen, e.g., if .he transmitted cotrnnunication/reques. a. 
; 204 was causing one or more of .he modules .o stop communicating). Mso tire phystcal 
comrection or power to the modules migh. have been lost, causing one or more mo ules to 
stop .inking. Therefore, eventual.y, it should be reported to tire user tha, me scan too. 10 has 
detected a communications drop-out, as shown at 222. 

The code shown in flowchart form in Figure 4 is intended to be relatively 
0 general. An example of code more specifically tailored to an OBD II environment 300 » 
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shown in Figure 5. Referring to that Figure, the eode 300 begins at 302 with the proeessor 12 
determining the protocol to use as taught in Figure 3 and the text aoeompanying that Ftgnre. 
If the protocol has previously been selected, then the process can skip to task 310. (As 
should be apparent, the protocol need no. he determined each time the user uses the dev.ee 
,0 to request information from the vehicle computer network 30, i.e., steps 302-308 are 
preferably done once each time the device 10 is connected to the vehicle computer network 
30 with subsequent accesses being done a. 312 using the protocol previously determmed at 
302 and the baseline determined at 308.) Next, at 304, the processor 12 tnmaltzes all 
modules in the network 30 using the se.ec.ed protocol. Then a. 306, the processor causes the 
communications circui. 14 to send a reques. .ha. all modules in me network 30 shou.d 
respond to, such as a Mode 1 HD 0 request Then .he processor saves tire IDs of the 
modules that respond to the request, at 308. Then a. task 310 whenever requesttng data or 
communicating with the vehicle computer network 30, such as a, task 312, me scan tool 10 
checks to be sure mat all ttte modules .ha. previously responded a. step 308 answer the 
reques. at 314 If all of the modules answer, a. 314, men there has been no commumcations 
drop-out and the code branches at 316 and can continue at 318 cither accessing more dan, or 
displaying the data, etc. On the other hand, if a. 314 one or more of the previous.y identified 
modules does no. does no, respond to the request issued a. 312, the code next de.crm.nes 
whether that specific module lost the link or whether that module merely ignored the request 
issued at step 204, e.g., that module does not support the request sent If the scan tool 10 
determines that .he module that did not respond is still communicating via that protocol, the 
scan tool 10 assumes that mat module merely ignored the request, e.g., i. does no. support the 
request If the non-responsive module is also no. communicating in response to more bas,c 
reouests, then the scan tool 10 concludes that there has been a communications drop-out. 
More specific to Figure 5, if a. 314 one or more of the previously identified modu.es does no. 
respond, the code branches a. 320 to step 322, where the code checks and determines agatn 
which modules are still linked, preferably using exactly tire same method as used ,n step 306, 
e g by issuing a Mode 1 MD 0 request If at step 324 the same modules are still tanked m 
response to the request issued at step 322 as were linked at step 308, then there has been no 
, communications drop-out and the code branches a. 326, and can continue at 328 ether 
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accessing more data or displaying the data, etc. On .he other hand, if a, 324 .he same 
m0 du.es are no. s,il. .inked in response .0 .he request issned a, s.ep 322 as were hnked a. step 
308 men there has heen a communications drop-ou. and me eode branches at 330, where the 
cede ,ncremen.s a conn.er (previous., zeroed) a. 332. If a. 334 me counter has reached a 
5 predeterminer, threshold, e.g., .hree (3), .hen .he eode branches a. 336 and nser is advrsed o 
the situation a. 338 (because .here have been n (e.g„ three) unsuccessful attempts a. 
communicating with that modu.e). The user is preferab.y prompted .0 do one or more of the 
Mowing: check the physical comtections (e.g., the connection between connectors 34, 36), 
ensure that the ignition key is on, ensure that the PCM power and ground axe OK, turn .he 
,0 ignition key off for .en seconds or so, and restart the entire process. If a. 334 me counter ts 
,ess than the predetermined number, the scan .ool 10 of the present invention does one or 
mo re of the following things to try .0 automatic* respond to the communications drop-ou. 
such as quieting the .ink or waiting for an idle period of time (e.g., on the order of ftom abou 
8 to abou, 10 seconds) a, 342 and attempting .0 perform a complete or partial intuahzatron of 
15 the modules via ttre selected pr„.oco. (or possibly reinitializing a.1 the protocols) a, 344. b, 
either even,, the code branches a, 346 .0 attempt the same request again, preferably usmg me 
same protocol determined at step 302 without re-determining the protocol. 

Another example of code specifically tailored ,0 an OBD II environment ,s 
shown in Figures 6-7. More specifically, Figure 6 shows a code subroutine that is used m 
20 Figure 7. It mis examples, a more basic request is issued ,0 test whether there has been a 
communications dropout, and whether any additions, modu.es have linked, before sendurg a 
m „re specific request. Referring firs, ,0 Figure 6, the subroutine 400 shown is essentta ly 
steps 322 through 342 of Figure 5, with an additiona. test 404 ,0 see if any more modules 
responded than had previously responded. The cede 400 begins a. step 402 where me code 
25 checks and de.ermines again which modules are still .inked, preferab.y using exact* the 
sanre method as used in step 506, e.g., by issuing a Mode , PD) 0 request. Next, a. 404, he 
code determines whether any additiona. modules have .inked ,0 the device 10. If at step 404 
to same modu.es are still .inked in response to the request issued a, step 402 as were finked 
a, step 508, .hen no additional modu.es have .inked and the code branches a. 406, and can 
30 continue a. 408 with a test .0 see if any modu.es have been dropped. On me other hand, ,f at 
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404 one or more additional modules have linked .o the devioe 10 than were linked a. step 
508 then the code branches a. 410, where the code adds the module IDs of the newly tanked 
modules to the list of module IDs previously generated and continues to step 408. At step 
408 the code determines whether any modules have dropped their communication tank with 
the device 10 by comparing the list of devices responding to the request issued at step 402 to 
,he list of module IDs that was previously generated at step 508 and possibly modified at step 
412 If so then there has been no communications drop-out and the code branches at 414, 
and returns at 416 and can continue cither accessing more data or displaying the data, etc. 
On the other hand, if a, 408 fire same modules are not still tanked in response to fire request 
issued at step 402, then there has been a communications drop-out and the code branches at 
418 where the code increments a counter (previously zeroed) at 420. This counter is tested 
at 422 and if the counter has reached a predetermined threshold, e.g., three (3), then the code 
branches at 424 and user is advised of the situation at 426 (i.e., there was a far.ure to 
determine a protocol because none of the protocols of Figure 3 resulted in a module 
providing any data or there has been a link failure because there have been n (e.g., three) 
unsuccessful attempts a. communicating with that module). The user is then preferably 
prompted to do one or more of the following: check the physical connecttons (e.g., the 
connection between connectors 34, 36), ensure that the ignition key is on, ensure that fire 
PCM power and ground are OK, turn the ignition key off for ten seconds or so, and restart 
the entire process. The user is also preferably given the option of exiting or res.ar.tng fire 
process. If the user was using cither View Data or Live Data, then fine user is preferably 
given the option of continuing the View data or Record Data with only the modules that are 
responding. The value of n that triggers user intervention could be user-selectable, as could 
the counter a. 332 that is tested a, 334. If at 422 the counter is less than the predetermined 
number, fire scan tool 10 of the present invention does one or more of fire following .lungs to 
ny to automatically respond to the communications drop-out, such as quietmg the tank or 
waiting for an idle period of time (e.g., on the order of from about 8 to about 10 seconds) at 
426 and returning a. 428 to attempt to perform a complete or partial initialization of the 
modules via the selected protocol (or possibly reinitializing all the protocols). 
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Tlre example of Figure 7 is intended to be used in modes where data is 
repeatedly acquired from me vehicle computer network, such as with the View Data (also 
known as Live Data) and Record Data functions. Referring now to Figure 7, the code 500 
begins at 502 with the processor 12 determining the protocol to use as taught in F.gure 3 and 
5 ,he text accompanying that Fignre. If the protocol has previously been selected, then .he 
process can skip to .ask 510. (As shou.d be apparent, .he protocol need not be de.erm.ned 
each time the user uses .he device 10 to request information from .he vehicle computer 
network 30, i.e„ steps 502-508 are preferably done once each time the device 10 is connected 
,„ the vehicle computer network 30, with subsequent accesses being done at 512 ustng the 
,0 protocol previously determined a. 502 and the baseline determined a, 508, possibly mod.fied 
a. 412 ) Next, at 504, the processor 12 initializes all modules in the network 30 ustng the 
selected protocol. Then a. 506, the processor causes the communications circuit 14 to send a 
request ma. all modules in the network 30 should respond to, such as a Mode 1 PID 0 
request. Then the processor saves the IDs of me modules that respond to the request a. 508. 
15 Then a. task 510 whenever requesting data or communicating with the vehicle computer 
network 30, such as a. task 512, the scan tool 10 checks to be sure thai all .he modules that 
previously responded at step 508 (possibly modified at step 412 of Figure 6) answer .he 
request, a. 512. However, prior to sending a request a. 512, the code tests whether all of the 
previously identified modules are still responding, at 514, by executing the subronrine of 
20 Figure 6. If the routine of Figure 6 returns via task 428, .hen a. least one module has lost d. 
communications link and the code continues a. 516 to task 518, where me code attempts to 
perform a complete or partial initialization of the modules via the selected protocol (or 
possibly reinitializing all the protocols). In either event, the code branches a. 520 to attempt 
the same test again, preferably using the same protocol determined at step 502 wrthont r=- 
25 determining the protocol. If a. 514 the routine of Figure 6 returns via task 416, then the code 
continues at 522 to send a request a. 5.2. If all of the modules answer, at 524, then there has 
been no communications drop-out and the code branches a. 526 and can continue at 528 
either accessing more data or displaying the dam, etc. On the other hand, if at 524 one or 
more of the previously identified modules does no. does not respond to the request tssued at 
30 512 the code branches at 530 and next determines whether that specific module lost .he hnk 
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or whether that module merely ignored the request issued a. step 512, e.g„ that module does 
no. support the request sent, by re-executing the routine of Figure 6, at 532. If the sean too. 
,0 determines that the nrndule that did not respond is still communioating via that protocol, 
i e the routine of Figure 6 returns via task 416, the scan tool 10 assumes that that module 
5 merely ignored the request, e.g., it does no. support the request, and .he code continues at 
534 either accessing more data or displaying the data, etc. If the non-responsive module is 
a.so no. communicating in response to more basic requests, i.e., the routine of Ftgure 6 
returns via .ask 428, men the scan too. 10 concludes that mere has been a communteattons 
drop-out and me code continues via 535 to teak 536 to perform a complete or pattial 
,0 initialization of the modules via the selected protocol (or possibly reinitializing all the 
protocols). In either event, the code branches a. 538 to attempt the same request agatn, 
preferably using the same protocol determined at step 502 without re-determining the 
protocol As discussed above, the example of Figure 7 is intended to be used in modes where 
data is repeated acquired from me vehicle computer network. As with Figure 5, the code of 
,5 Figure 7 can be used with functions that use a one-time access. Preferably, however, only a 
subset of the code of Figure 7 is used for functions involving a one-time access of the vehtcle 
computer network 30, snch as reading diagnostic .rouble codes (DTCs), reading oxygen 
monitors, reading any pending codes, erasing codes, reading vehicle information, etc. In .he 
case of these one-time accesses, one preferably uses only .asks 502 through 522, and uses 
20 whatever data is returned in response to the request a. .ask 512, wtthon, performing the 
functions of tasks 524 through 536. 

While the present invention has been illustrated by the descriptton of 
embodiments thereof, and while .he embodiments have been described in some detail, it is 
no, the intention of the applicant to restrict or in any way limit me scope of the appended 
25 claims to such detail. Additional advantages and modifications will readily appear to those 
skilled in the art, for example, using fiber optic or wireless protocols. Of comae, m me OBD 
H context, a Mode 1 FID 0 request need not be used; other codes might flush out the 
available modu.es and monitors. As another example, the teachings of the present inventton 
are no. limited to scan tools, per se. Tney can, for example, be implemented in other off- 
30 board devices, such as in PC-based emissions and maintenance test systems, such as those 
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fomd a, nrany state EPA testing centers and in end-of-Un. teste, u*d by — 
»«» Therefore, the invention in its broader aspects ,s no, hurt to *e speetf 
deBils representative apparatus and tnethods, and illustrative examples shown and 
ZLl Accordingly, departures may he made from sueh details without departtns from 
5 the spirit or scope of the applicant's general inventive concept. 



{C-B0390.DOC;!} 



